POC: Add config-driven sensor alert dashboard - #322
Open
jirhiker wants to merge 2 commits into
Open
Conversation
Introduces a unified dashboard for telemetered sensor sources, starting with Van Essen Diver and Wellntel. It serves the two operator questions: is every logger healthy, and what new data is waiting to be ingested. Adding a source is a configuration change only. A source is declared in src/config/sensor-sources/sources/ via defineSensorSource(), which specifies its transport, vendor field mapping, displayed metrics, alert rules, and ingestion target. The alert engine, device grids, and mock provider are all driven off that registry and contain no per-source branching. Alert rules are declarative (stale / threshold / range / gap) so new failure modes are expressed as config rather than code. The config is Zod-validated at import time, and additionally rejects rules pointing at undeclared metrics, duplicate rule ids, and critical bounds that are less severe than their warning bound -- each of which would otherwise produce a rule that silently never fires. The OcotilloAPI sensor-source endpoints do not exist yet. The expected contract is documented in src/interfaces/sensor-dashboard, and VITE_SENSOR_MOCK=true serves fixtures generated from the same configs so the dashboard is fully exercisable until the backend lands. Vendor field paths in both source configs are modelled, not verified against live API responses; they are marked TODO(vendor-docs) and are correctable in one file per source. Viewing is open to AMP viewers; triggering an ingestion run writes to the observation tables and is gated on editor/admin at both the route and the button.
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
Preview DeploymentPreview URL: https://preview-sensor-dashboard-auejgdbofq-uc.a.run.app Note: This preview uses the staging API endpoints. |
Preview deploys have no sensor backend to talk to, so the dashboard now defaults to generated fixtures there, keyed off the VITE_APP_ENV=preview that CD_preview.yml already sets. Staging and production build with their own VITE_APP_ENV and are unaffected. The fallback deliberately fails towards real data: a build that forgets to set VITE_APP_ENV gets mocking off, so it surfaces an honest error rather than convincing fake sensor readings. VITE_SENSOR_MOCK still overrides in either direction, and a blank value (which is what Docker sets for an unpassed ARG) is treated as "no override" rather than as an explicit opt-out. Because getting this wrong in the wrong direction would put fabricated readings on a production dashboard, the resolution rule is pinned by tests covering preview, staging, production, missing VITE_APP_ENV, and both override directions. Also strengthens the in-page notice: it now reads as a warning that every device and reading is generated and that triggering a run writes nothing, rather than an aside aimed at developers.
Preview DeploymentPreview URL: https://preview-sensor-dashboard-auejgdbofq-uc.a.run.app Note: This preview uses the staging API endpoints. |
jirhiker
changed the title
Collaborator
|
This is awesome. My two cents and dreaming on top of this (just me, no user research): I could eventually see a "sensor" or "equipment" menu item being the overall home to a few different things like this, such as:
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
POC:⚠️ Do not merge. This is poc/mock up. gauge user interest/engagement before proceeding
Unified alert dashboard for telemetered sensor sources, starting with Van Essen Diver and Wellntel. Serves the two operator questions: is every logger healthy, and what new data is waiting to be ingested.
Adding a source is a config change only
A source is declared in
src/config/sensor-sources/sources/viadefineSensorSource()— transport, vendor field mapping, displayed metrics, alert rules, ingestion target. The alert engine, device grids, and mock provider all read from that registry and contain no per-source branching.Verified live: Van Essen renders Battery/Signal/Memory/Water level/Temp columns and Wellntel renders Battery/Signal/Depth/Confidence, purely from their configs.
Declarative alert rules
Four kinds —
stale,threshold,range,gap— so new failure modes are config, not code. Beyond Zod parsing,defineSensorSource()rejects three things that would otherwise yield a rule that silently never fires:Backend does not exist yet
OcotilloAPI has no telemetry ingestion —
wellntelandvan essenboth return 0 grep hits, andtransfers/is a deprecated one-shot CSV migration. The expected contract is documented insrc/interfaces/sensor-dashboard/index.ts:VITE_SENSOR_MOCK=trueserves fixtures generated from the same configs, so the dashboard is fully exercisable until the backend lands. Flipping the flag is the only change needed. It defaults on under test and is setfalsein.env.production.example.Reviewer notes
TODO(vendor-docs)and correctable in one file per source.src/test/utils/accessControl.test.tsis an intentional guard requiring new routable resources to be declared — updated accordingly.settings.rowHeight(27px), which crops the status chips.Verification
tsc --noEmitcleanvitest run --dir src, with the Prism mock server up), including 31 new tests for the alert enginenpm run build:fastsucceedsrunning-> poll ->succeeded, 48 records ingestedTwo bugs found and fixed by running it: the alert list was flooded by a single failing logger (now capped per device), and alert rows did not name their source when two vendors had a same-numbered point.
🤖 Generated with Claude Code